In a basic database client/server arrangement, one or more database clients can make queries via a network to a back-end database server. The database server executes the queries and returns results to the client that requested them. The clients might be, for example, web servers or application servers or a mix of both. Typically all the clients transmit their queries to a common IP address and port number combination on the database server, and the database server transmits its results back to the IP address that originated each query. Usually an authentication process precedes the queries, in which the client provides the database server with authentication credentials (such as a username and password) and the database server establishes a “connection” through which the client can make its queries. A database server in this basic arrangement is often a single computer system, though in some implementations it might actually be a cluster of computer systems. Even such a cluster, however, is arranged so as to appear to the client as a single server reached via a single IP address and port number combination.
In a traditional database client/server arrangement, the database server(s) handle the job of user authentication. This includes having data of user account details, loading them into the buffer on request and executing the user authentication process. The authentication process itself can be fairly complicated, at times involving compute-intensive encryption, decryption and/or hashing, or other challenge type methods that tend to slow down the process of establishing a connection to a database. For example, in one conventional arrangement, when the database server receives a connection request from a client system, it sends a “challenge” transmission back to the client system. The “challenge” transmission includes a random string, sometimes called a “scramble”. The client system receives the challenge and calculates a token using an algorithm such as the following:                stage1_hash=SHA1(user-entered password);        token=SHA1(scramble+SHA1(stage1_hash)) XOR stage1_hash,where SHA1 is a hashing algorithm, and ‘+’ is a concatenation operator. The client system sends a “response” transmission to the database server, which includes the token. The server then checks the validity of the response by calculating:        stage1_hash′=token XOR SHA1(scramble+mysql.user.Password),where mysql.user.Password is SHA1(SHA1(user's password)), and was stored previously at the server. The server then compares SHA1(stage1_hash′) with mysql.user.Password. If they match, then the request is considered authentic and the server sends an “OK” result transmission back to the client system. Only then will database queries from the client system be accepted by the server.        
It can be seen that significant compute-intensive calculations take place at both the client system and the database server in a challenge/response authentication protocol such as this. The problem is compounded because in many traditional database client/server arrangements, a client might make only one or a few queries through an authenticated connection to the database server, before it tears down the connection. Once the connection is torn down, another full challenge/response authentication process must take place, complete with a new scramble and new compute-intensive calculations at both the client system and the database server, before the client system can make new queries to the database server.
Applicants have recognized that the authentication process can be a significant burden on database servers. At the network level, mechanisms exist that can offload the authentication burden from servers. These are network level or operating system level authentication mechanisms, however, such as Microsoft® Windows Active Directory, basic HTTP authentication, RADIUS, and SSL. Many database client/server arrangements implement database level authentication mechanisms in addition to any that might be implemented on the network generally. Database level authentication can limit access to the database to fewer than all the users that have network level authentication, so that a secure database can co-exist on a network that also supports many other applications. Database level authentication also can define user-specific access controls to different sub-components of the database environment, about which the network level authentication mechanisms have no knowledge (such as individual databases, tables or access types).
It may also be that some sophisticated database environments might implement mechanisms to offload database level authentication processing. However, many less sophisticated kinds of client/server database arrangements do not. It may be possible to add a database level authentication offload feature to such arrangements, but typically this would require modification to the database server software. This can be expensive, and time consuming, and in some cases may require significant re-engineering of its underlying structure, rendering it incompatible with future updates to the original server software. Closed source software that do not support code editing are not even capable of being modified to handle database level authentication offload, or may be legally protected from such modification.
Thus Applicants have recognized a need for a mechanism which can offload the database authentication process, and do so transparently without requiring modification of software code in either the client application or the database servers.